Many server applications and various types of software applications in general are capable of sending and receiving information from other network connected applications. A well known type of server application is a “web server” which is available to many “web clients” and operates to serve web pages to those web clients upon request. For example, a user working at a client machine can launch a web browser, such as Firefox™ and navigate to a website via the web browser. When the user instructs the web browser to navigate to a web site, the web browser makes an HTTP (Hyper Text Transfer Protocol) request to a web server operating on a remote server. Web server software, such as Apache™, accepts the HTTP request, and returns a web page to the web browser client, which is displayed for the user and appears as one page of a web site.
Most network connected software applications receive incoming requests via pre-determined “ports,” which associate a particular type of incoming data or request with an intended software application to service requests or process the data in some manner. For example, web servers customarily receive HTTP requests at port 80, HTTPS (HTTP over Secure socket layer) requests are customarily received at port 443, and the now defunct “finger protocol” application traditionally operated at port 79.
Some server applications are capable of operating on and receiving information from multiple ports through the use of multiple “sockets” internal to the server application. A socket is the combination of a known Internet Protocol (“IP”) address and a specific port number. Other server applications, such as “finger” or rudimentary implementations of FTP (File Transfer Protocol) are incapable of receiving information from multiple ports because they lack the necessary logic to support multiple sockets which enable the server application to receive information at the multiple ports.
Supporting multiple ports through multiple sockets makes an application inherently more complex, although the use of standardized libraries can simplify the necessary logic. Application developers must balance the complexity inherent in supporting multiple ports with the underlying functional goals of the application. A single socket application is faster and simpler to develop, though less feature-rich, while a multi-socketed multi-port application yields a greater feature set, but is more costly and complex to develop. Furthermore, single-socket applications will generally consume fewer system resources than multi-socket applications due in part to the simplified application's logic.
The problems with single-socket applications become exacerbated when those applications are being used by a large number of clients, such as a publicly available network service. Each client must be configured to connect with the appropriate port, e.g. port 10,000, supported by the application. If that port should change for whatever reason, e.g. from port 10,000 to port 443, all clients configured to connect to the old port (10,000) would receive an error, as their communication attempt would fail as it is no longer associated with the server application. A system administrator responsible for the service could send users instructions on reconfiguration, but as the number of users increases, the potential for support problems and upset users increases dramatically due to reconfiguration errors, users not receiving the notices, or users failing to understand the timing of the change, and so forth.
Alternatively, the single-socket application could be modified, but doing so presents a significant cost and enormous technical complexity depending on the application, especially for older “legacy” type services that may no longer have active development support teams, but are still in use by an enterprise. More sophisticated multi-socket applications do not present such a problem, as the multi-socket application may simply be reconfigured to monitor an additional port without ceasing to provide services at a previously used port. This reconfiguration could accommodate clients of a new port without adversely affecting clients attempting to connect with an old port.